Electronic control system for automobile

ABSTRACT

In an ECU, a flash ROM has a main storage area for storing a current version of an application program and a sub-storage area for storing update version program that includes updated points from the current version program. A rewriting tool executes program rewrite processing including: store processing of storing the update version program in the sub-storage area; and memory changeover processing in which, when the writing of the update version program in the sub-storage area has been done successfully, the sub-storage area where the storing of the update version program has ended is changed over to a new main storage area instead of a memory area currently being used as the main storage area. When the writing in the sub-storage area has failed, the changeover is not conducted.

CROSS REFERENCE TO RELATED APPLICATION

This application is a Division of application Ser. No. 12/805,254, filedJul. 21, 2010, which is a Division of application Ser. No. 11/407,130,filed Apr. 20, 2006 and is based on Japanese Patent Applications No.2005-122734 filed on Apr. 20, 2005 and No. 2005-125518 filed on Apr. 22,2005, the disclosures of each of which is incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to an electronic control system for anautomobile.

BACKGROUND OF THE INVENTION

Automobiles are equipped with electronic control units (ECUs) each forcontrolling various electronic apparatuses to be controlled. Each ECUhas a main control unit composed of a CPU, and performs controlprocessing of electronic apparatuses mounted on the automobile based onexecution of predetermined control software. This control software isrecently stored in a flash ROM (flash memory) so that its contents canbe updated at any time for version-ups, correction of bugs, etc. ofstored application programs (U.S. Pat. No. 6,249,848 corresponding to JP10-111863A; US 20030221049A1 corresponding to JP 2003-337748A; JP2003-172199A; and JP 2001-229014A).

Conventionally, update processing of an application program is oftendone in a car dealer shop etc. into which the owner brings in a vehicle.In recent years, the spread of vehicle external infrastructures usingradio communication (for example, a portable phone network etc.) ispaving a way to possible scenario of addition of functions and updatingof map data in a car navigation system, distribution of music softwareused by the car audio system, etc. which might be executed by the usersthemselves. In this case, the update processing is performed bydownloading an update version of control software by wireless receptionfrom the external infrastructure and writing it in a flash ROM, whilethe user is using a vehicle.

The stored program is updated to a new version, while the old versioncontrol software is being used by the user. The rewrite processing isperformed by overwriting (or invalidating) an old version of controlsoftware in the flash ROM. In case where the rewrite processing of a newversion of software has failed for some reason (for example,communication failure, bugs and erroneous operation of rewriteprocessing, hardware abnormality, etc.) during the rewrite processing,old version software as well as new version software becomes unusable orsuffers dysfunction. This causes serious influence on providingfunctions to the user.

Further, when the update processing is to be performed, it is necessaryto perform version-up processing of the application program (functioncontrolling software) of an automobile using a program for rewriting(rewriting firmware) prepared apart from the function controllingsoftware. In the case of an ECU carried on an automobile, in contrast toOS etc. of a personal computer, it is rare that the users direct theirattentions to rewrite processing itself regarding version-up of themounted application program. In most cases, a person in charge of adealer shop performs the rewrite processing actually. For example, inthe case where the ECU is configured to start an extra routine regardingrewriting of the application program when the ECU is restarted afterresetting, not only the ECU does not operate automobile functions thatthe user usually enjoys but also transfers into an input waiting stateof the rewrite processing, which the user can hardly understand and maybe driven into confusion. By such a reason, when restarting the ECUafter resetting it, the ECU is configured in such away that a main bodypart (function realizing program part) of the application program startsalways before the rewriting program. In the case where the ECU isintended to transfer to the rewrite processing, the rewriting firmwareis started by command input from this application program specifically,in one of execution steps of the above application program, therewriting firmware receives a start command being entered from aninterface for maintenance that general users do not operate usually. Forexample, it is realized in a touch panel screen that is called by anexclusive command or by input tool connection to an exclusive connector.

Meanwhile, when the rewrite processing is performed in such a way thatan update version program is overwritten on an old version program(invalidated) in a flash ROM, there is a case where the rewriteprocessing fails because of some cause (for example, electric powercutoff of the ECU, communication failure, bugs and erroneous operationof the rewrite processing, hardware abnormality, and connector dropoutin the case where rewriting is performed with an exclusive rewritingtool bearing the update version program being connected to an in-vehiclenetwork, and the like) during the rewrite processing of the updateversion program. In this case, the failure causes the old versionprogram as well as the update version program to be unusable or fallinto dysfunction, which gives serious effects on providing functions tothe user. As a natural consequence of this, it is required to performagain the rewrite processing of the application program.

However, like the above conventional ECU, when the rewriting firmware isconfigured to receive the start instruction from the application programside, once the rewrite processing of the application program fails,normal start of the application program cannot be expected at all afterthat. As a result, it is no longer possible to start the rewritingfirmware in order to repair this. Therefore, re-execution of the rewriteprocessing will become impossible. In this case, what is required inorder to solve this problem is to remove the ECU, attach it to anexclusive apparatus, and rewrite the contents of the flash ROM thatstores the application program. However, it takes much time to removethe ECU mounted in a deep location of the vehicle body, which will leadto waste of unexpected time and labor for normal restoration.

SUMMARY OF THE INVENTION

The present invention therefore has a primary object to provide anelectronic control system for an automobile that can perform rewriteprocessing of control software stored in a nonvolatile memory in such away that even when the rewriting fails, the system can ensure providingof functions to a vehicle user.

The present invention has a secondary object to provide an electroniccontrol system for an automobile equipped with a function of, even whenrewrite processing of controlling software loaded on a nonvolatilememory fails by any chance, being able to perform the re-rewriteprocessing surely.

According to a first aspect of the present invention for attaining theprimary object, a main storage area for storing the current versionprogram of a control software and a sub-storage area for storing a newlyacquired update version program are provided in a nonvolatile memory forstoring the control software, and the update version program acquiredfrom the outside is stored in a sub-storage area that is allocatedseparately from the main storage area for storing the current versionprogram currently being used. Then, when the writing of the updateversion program in the sub-storage area has been done successfully, thesub-storage area in which storing of the update version program hasended is changed over to a new main storage area instead of the memoryarea currently being used as the main storage area. When the writing inthe sub-storage area has failed, the changeover of the storage area isnot conducted. By this, even when the writing of the update versionprogram has failed, the current version program remains undamaged in themain storage area, processing of changing over the sub-storage areawhere only incomplete update version program is written to the mainstorage area is not conducted. Accordingly, the current version programcan be used continuously, which ensures a capability of providingfunctions to the user even at the time of failure of rewriting.

The nonvolatile memory provides its storage area that is divided into aplurality of rewriting unit blocks and such that erasing, writing andrewriting of the storage contests are made possible only on a rewritingunit block basis (typical example is flash memory or flash ROM). In thiscase, it is desirable that the main storage area and the sub-storagearea are formed in mutually different rewriting unit blocks.

For example, recently the development in the capacity of the flashmemory has been progressing rapidly to achieve the capacity large enoughto store control software of a large size. In the present aspect, whenthe program is described in the address space in a relocatable manner,it is even possible to form the main storage area and the sub-storagearea in a memory space with appropriate varying locations in the memoryspace, considering the size and location of a free area in the memory.Although, the storage contents of the flash memory can be rewrittenelectrically, it is impossible to rewrite in bits as in a RAM, that is,the flash memory has a physical structure that allows rewriting only inblocks of a fixed size because the drive voltage at the time of readingand the drive voltages at the time of erasing differs from each other.With this structure, when the main storage area and the sub-storage areaare set in the memory not being limited by locations in the addressspace allocated in the nonvolatile memory, it is likely that both themain storage area and the sub-storage area are formed in the samerewriting unit block. There is a risk that the program data in the mainstorage area may be broken when, for example, there occurs a trouble,such as erroneous operation, at the time of writing an update version inthe sub-storage area. Contrary to this, when the main storage area andthe sub-storage area are formed in mutually different rewriting unitblocks, such a trouble will not occur.

In this case, the nonvolatile memory has the first memory and the secondmemory that are formed as a fixed memory consisting of a group of theirown rewriting unit blocks, and the program rewriting means may beconfigured to form the sub-storage area alternately in the first memoryand the second memory. Thus, it specifies in which one of the firstmemory and the second memory the main storage area and the sub-storagearea are alternately formed, respectively, each time an update versionprogram is newly acquired for the same control software, wherebyprocessing of executing program update processing of the same controlsoftware repeatedly can be performed simply and rationally. Moreover, asa natural consequence of adoption of this system, in the memory areathat is used for formation of the sub-storage area, only a formerversion program older than the current version program is stored, andconsequently the degree of freedom of overwriting and erasing is high.Consequently, in writing an update version program, extra processing,such as data saving etc., can be kept to a minimum, and the processingneeds a fewer number of steps of read-and-write processing. In thiscase, when the program rewriting means sets up the sub-storage area insuch a way that the sub-storage area is rewritten over a memory that theprevious version program older than the current version program used asthere main storage area, it is possible to keep a memory area that willbe newly consumed at the time of rewriting to a minimum, effectivelyutilizing the capacity of the volatile memory.

Here, the above first memory and the above second memory can be formedbeing partitioned in a memory space of the same nonvolatile memory chip,or the first memory and the second memory can be formed in individualnonvolatile memory chips. In the former case, the number of nonvolatilememory chips is reduced, contributing to reduction in hardware cost.However, there is a problem in which, when hardware abnormality of thenonvolatile memory chip occurs, both the first memory and the secondmemory causes errors. On the other hand, in the latter case where thefirst memory and the second memory are formed in individual nonvolatilememory chips, hardware cost increases because of extra nonvolatilememory chip, switching mechanism for switching over memory, and the likebecome necessary. However, there is an advantage that even when one ofnonvolatile memory chips is broken, the other nonvolatile memory chipcan be utilized as a chip for back up.

Next, program rewriting means can be configured to write the updateversion program along with version information for specifying theversion in the sub-storage area. In this case, it is possible to providea control software starting means that, in executing the controlsoftware after the updating, accesses to storage areas of programs ofdifferent versions that are stored in the first memory and in the secondmemory, respectively, reads and compares version information given tothe respective programs, and uses a program, that was identified as anew version, as a current version program. Since in the present aspect,the current version program and the update version program of the samecontrol software temporarily co-exist in the nonvolatile memory, theboth program can be identified properly, so that a trouble oferroneously executing the old version program after the updating can beprevented.

In this case, the program rewriting means can be configured to write theupdate version program along with the normal termination information inthe sub-storage area in response to the normal termination of the updateversion program. Moreover, the control software starting means can beconfigured to permit only a program having the normal terminationinformation to be started. That is, in the case where a program to beexecuted is determined only by identification of the above versioninformation, the following contradiction is brought about: even in thecase where writing has not normally ended, when only the versioninformation is renewed, the incomplete program will be executed. On thecontrary, by writing normal termination information along with theversion information, it can be properly grasped whether the updateversion program has been written so as to be usable normally, and thussuch contradiction can be eliminated. In this case, when the versioninformation indicates a new version and is accompanied with the normaltermination information, the update version program is put for executionand as a result the sub-storage area was changed over to the mainstorage area.

The first memory and the second memory can be specified to store aplurality of control programs having different functions, respectively.In this case, the program rewriting means can be configured so as todetermine independently in which memory the main storage area and thesub-storage area will be formed each time program updating occurs inindividual control software. Consequently, the main storage areas andthe sub-storage areas of each of different control software will beformed mixedly in the first memory and in the second memory depending onthe number of updating the each control software. However, by writingthe version information described above, the main storage area and thesub-storage area of each of various control software that are formedmixedly can be identified without problems, so that for each of multiplepieces of control software coexisting in the nonvolatile memory atrouble of erroneously executing an old version of a program afterupdating can be prevented.

The above nonvolatile memory can be kept to store the rewriting firmwarethat is function realizing firmware of the program rewriting means. Inthis case, the CPU can be programmed to perform the program rewriteprocessing independently from execution processing of the currentversion program when the update version program was acquired. By this,the CPU can perform program rewrite processing in the background ofexecution processing of the current version program, and accordingly itbecomes possible to reduce or eliminate a period when functions based onthe targeted control software is unusable because of program rewriting.

In this case, there can be provided control-software start controllingmeans for controlling start states of multiple pieces of controlsoftware and common operation rest period specifying means thatspecifies the common operation rest period in which all pieces ofcontrol software commonly halt their operations based on a start controlstate by the control-software start controlling means. The rewritingfirmware can be designed as one that performs program rewrite processingin the specified common operation rest period. With this configuration,since the program rewrite processing is performed using a rest periodthat is common to multiple pieces of control software, individualcontrol software becomes less prone to suppression resulting from a loadof background processing for program rewriting. Accordingly, thisconfiguration makes it possible to effectively inhibit a trouble inwhich a processing speed of specific control software reduces extremely,an operation response of an automobile function corresponding to thecontrol software is delayed, and the like.

In this case, when the rewriting program is made to perform the programrewrite processing using time division processing that extends over twoor more common operation rest periods coming one by one in a sequentialmanner, the above effect can be enjoyed even in the case where theupdate target control software is large in size.

For example, in the case where the control-software start controllingmeans has a scheduler for starting and controlling execution tasks ofmultiple pieces of control software periodically in a predetermined timeseries sequence, the rewriting firmware can be configured as softwarethat, when performing program rewriting process, conducts time divisionprocessing in such a way that a task of program rewrite processing isincorporated in an execution task array of a plurality of applicationprograms in the scheduler. By this configuration, it is possible toeffectively prevent a trouble in which a load by background processing(as viewed from an individual application program) of program rewritingis imposed unequally to a specific application program.

In the above mode, the scheduler also serves as common operation restperiod specifying means, and is configured to form the common operationrest period compulsorily by incorporating a task of program rewriteprocessing in the execution task array of the application program.Alternatively, it is also possible for the common operation rest periodspecifying means to specify the common operation rest period as a periodwhen there is no outside start request to any of a plurality ofapplication programs. In this case, there can be provided sleepcontrolling means so that, when the update version program is notacquired in the common operation rest period, the CPU is subjected tosleep setting that shifts the CPU to a sleep mode with a smaller amountof power consumption than the normal operating mode. When the updateversion program is acquired in the common operation rest period, programrewrite processing by rewriting firmware is started. That is, theprogram rewrite processing is started after the coming of a period ofsuch light processing load that there is no operation request forautomobile functions corresponding to any application program and, whenit is a normal state, the CPU is made to enter a sleep mode, whereby itis possible to reduce a possibility that execution processing of each ofapplication programs is suppressed.

According to a second aspect of the present invention for attaining thesecondary object, each time the rewrite processing of functioncontrolling software is performed, information as to whether it hasnormally completed is stored as rewriting-state identifying informationevery time. Then when the function controlling software is tried to bestarted next, first the content of rewriting-state identifyinginformation is referred to, not that the function controlling softwareis started immediately. As a result, in case where it is turned out thatthe pervious rewrite processing was faulty, rewriting firmware isstarted again instead of the function controlling software. That is, thestart command of the rewriting firmware is not executed inside thefunction controlling software, but the start controlling means that isindependent from the function controlling software refers to therewriting-state identifying information and subsequently restarts therewriting firmware independently. Therefore, even when rewriting of thefunction controlling software fails, re-rewrite processing of it can beperformed surely.

The identifying information rewriting means invalidates the storagestate of the rewriting-state identifying information storage part as ofbefore starting the rewriting firmware at the time of starting thefirmware, and subsequently sets the storage state of the rewriting-stateidentifying information storage part to a predeterminedrewriting-normally-completed state that indicates rewriting normalcompletion after the rewriting firmware has normally completed therewrite processing of the function controlling software in thenonvolatile memory. The start controlling means can be configured tostart the function controlling software only when the memory content ofthe rewriting-state identifying information storage unit is therewriting-normally-completed state. It can be determined surely whetherthe rewriting of the function controlling software is succeeded byinvalidating the content of the rewriting-state identifying informationstorage part at the time of rewriting the function controlling softwareand by setting the content of the rewriting-state identifyinginformation storage part to the rewriting-normally-completed state whenthe rewrite processing has normally completed. As a result, this alsomakes it possible to shift smoothly to the re-rewrite processing by therewriting firmware in the case of unsuccess.

The identifying information rewriting means sets the memory content ofthe rewriting-state identifying information storage part to apredetermined under-rewriting state that indicates under-rewriting inresponse to the start of the rewrite processing of the functioncontrolling software by the rewriting firmware, and also maintains theunder-rewriting state until the rewrite processing of the functioncontrolling software has normally completed. The start controlling meanscan start the rewriting firmware, provided that the memory content ofthe rewriting-state identifying information storage part is set to theunder-rewriting state. With these means for doing such processing, afact that the memory content of the rewriting-state identifyinginformation storage part remains to be the under-rewriting state impliesthat the last rewrite processing failed halfway. Therefore, by startingthe rewriting firmware immediately, shift to the repair processing canbe done quickly.

The rewriting firmware can be configured to acquire an update versionprogram of the function controlling software to be used for rewritingfrom a data sender apparatus connected to the control system bycommunication and performing rewriting with it. In this case,identifying information rewriting means can be configured to maintainthe memory content of the rewriting-state identifying informationstorage part at the under-rewriting state by receiving an instruction ofmaintaining a state of rewriting received from the data senderapparatus. According to this method, it becomes possible to grasp moresurely a state of transfer and writing of the update version program bycooperating with a data sender apparatus, and reliability concerned withsetting of the under-rewriting state is improved considerably.

In this case, identifying information rewriting means periodicallyreceives an instruction of maintaining a state of rewriting during aperiod from the start of the rewrite processing of the functioncontrolling software to its normal completion. When the identificationrewriting means is configured to maintain the memory content of therewriting-state identifying information storage part at theunder-rewriting state, the above effect can be enhanced further. Forexample, provided that the rewriting firmware receives the updateversion program as divided into a plurality of blocks sequentially fromthe data sender apparatus, the identifying information rewriting meanscan be configured to receive an instruction of maintaining a state ofrewriting for each block.

Next, the identifying information rewriting means can be configured toset the storage state of the rewriting-state identifying informationstorage part to the rewriting-normally-completed state when therewriting firmware has written the whole of the update version programreceived from the data sender apparatus in the nonvolatile memory andhas verified the update version program written based on verifying datareceived from the data sender apparatus. Since therewriting-normally-completed state is set up after verification, thissetting can improve reliability when the written update version programis being used. In this case, the identifying information rewriting meanscan be configured to, when the rewrite processing by the rewritingfirmware has failed during the verification, set the memory content ofthe rewriting-state identifying information storage part to theunder-rewriting state in such a way that makes it possible to specifythat the rewrite processing failed during the verification.Corresponding to this, the start controlling means can be configured torestart the rewriting firmware so that the rewrite processing is resumedfrom the verification processing. With these configurations, regardingthe failure in a stage of verification it is not necessary to go back towrite processing of the update version program and only the verificationprocessing needs to be conducted again, and consequently the re-rewriteprocessing can be simplified significantly.

Moreover, the identifying information rewriting means can be configuredto, when the rewrite processing of the function controlling software inthe nonvolatile memory of the rewriting firmware has failed halfway, setthe memory content of the rewriting-state identifying informationstorage part to the under-rewriting state in such a way that aninterruption location of the rewrite processing (in addition to therewrite processing in the nonvolatile memory, the verificationprocessing of written data is included) can be specified. In this case,the start controlling means can be configured to specify theinterruption location from the memory content of the rewriting-stateidentifying information storage part and restart the rewrite processingfrom that interruption location. With these configurations, when therewrite processing is interrupted halfway, the rewrite processing by therewriting firmware can be resumed from the interruption location, andconsequently the re-rewrite processing can be simplified considerably.

Although theoretically, resolution in specifying the above interruptionlocation can be enhanced to a unit of bit constituting the updateversion program data, in this case, it is necessary to accompany eachbit with rewriting-state identifying information, and accordingly atotal size of the rewriting-state identifying information becomesextremely large. This leads to useless consumption of the memory. Forexample, in the case where the rewriting firmware receives the updateversion program as divided into a plurality of blocks (naturally, eachconsists of multiple bits) sequentially from the data sender apparatus,the identifying information rewriting means can be configured to, whenthe rewriting firmware has interrupted the rewrite processing of thefunction controlling software in the nonvolatile memory halfway, set thememory content of the rewriting-state identifying information storagepart to the under-rewriting state in such a way that makes it possibleto specify in which block the rewrite processing has been interrupted.In addition, the start controlling means can be configured to specify ablock on which the processing is interrupted from the memory content ofthe rewriting-state identifying information storage part and restart therewriting firmware so that the rewrite processing is resumed from thatblock. In this method, the rewriting-state identifying information onlyneed be accompanied with each block, and enlargement of its total sizecan be prevented.

The multiple rewriting-state identifying information storage parts canbe installed, each corresponding to each block of the update versionprogram. The rewriting firmware can be configured to set storage statesof the plurality of rewriting-state identifying information storageparts to the rewriting-normally-completed states sequentially on afirst-completion first-setting basis. The rewriting-state identifyinginformation storage part can be configured to restart the rewritingfirmware in such a way that the rewrite processing is resumed from ablock whose storage state of the rewriting-state identifying informationstorage part is not set to the rewriting-normally-completed state. Withsuch configurations, it is possible to grasp quickly and properly towhich block the rewrite processing has normally completed bysequentially checking the contents of the rewriting-state identifyinginformation storage parts of the blocks whose rewriting order has beenfixed.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the presentinvention will become more apparent from the following detaileddescription made with reference to the accompanying drawings. In thedrawings:

FIG. 1 is a block diagram showing a first embodiment of an ECUconfigured as an electronic control system for an automobile of thepresent invention;

FIG. 2 is a schematic diagram illustrating an in-vehicle network where aplurality of ECUs is connected together;

FIG. 3 is a schematic diagram of a scheduler;

FIG. 4 is a schematic diagram illustrating executing reprogramprocessing by incorporating it into a task array by the scheduler;

FIG. 5 is a flowchart showing one example of scheduler controlprocessing;

FIG. 6 is a flowchart showing one example of sub-storage areadetermination processing;

FIG. 7A is a flowchart showing a first example of reprogram processing;

FIG. 7B is a flowchart showing a second example of reprogram processing;

FIG. 8 is a flowchart showing one example of application program startprocessing;

FIG. 9A is a timing chart showing one example of making sleep setting ina plurality of stages;

FIG. 9B is a flowchart showing one example of sleep control processing;

FIG. 10A is a block diagram showing a second embodiment of an ECUconfigured as an electronic control system for an automobile of thepresent invention;

FIG. 10B is a flowchart showing an example of reprogram processing inthe second embodiment;

FIG. 11 is a block diagram showing a third embodiment of an electroniccontrol system for an automobile of the present invention;

FIG. 12 is a schematic diagram illustrating an application programstorage area of a flash ROM;

FIG. 13 is an explanatory diagram showing another setting example of anidentifying ID;

FIG. 14 is a schematic diagram of rewrite processing;

FIG. 15 is a flowchart showing a first example concerned with details ofthe rewrite processing;

FIG. 16 is a flowchart showing start control processing that correspondsto the rewrite processing of FIG. 15;

FIG. 17 is a flowchart showing a second example concerned with detailsof the rewrite processing;

FIG. 18 is a flowchart showing start control processing that correspondsto the rewrite processing of FIG. 17;

FIG. 19 is an explanatory diagram showing an example of formingblock-based identifying ID storage parts in storage areas of respectiveblocks in an application program storage area;

FIG. 20 is a flowchart showing a fourth example concerned with detailsof the rewrite processing;

FIG. 21 is a flowchart showing start control processing that correspondsto the rewrite processing of FIG. 20;

FIG. 22 is an explanatory diagram showing an example in which theblock-based identifying ID storage parts of respective blocks are formedoutside the block storage areas collectively;

FIG. 23 is a diagram showing rewriting identifying information of acombination of a block counter and the identifying ID; and

FIG. 24 is a flowchart showing a fifth example concerned with details ofthe rewrite processing.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment

Referring to FIG. 1 showing an electrical configuration an electroniccontrol unit (ECU) of an electronic control system for an automobile, anECU 1 has a main control unit made up of a CPU 3 and performs controlprocessing of electronic apparatuses mounted on an automobile as controltarget apparatuses to be controlled based on execution of apredetermined application program (control software) 18. The maincontrol unit is further made up of a ROM 5, a RAM 4, and amicroprocessor to which an input/output unit (I/O port) 2 arebus-connected. The ECU 1 is constructed as a body (chassis) system ECUfor handling a control of a body system of an automobile in thisembodiment. Each of application programs 18 operates on a platform 5 b,and an individual work area therefor is ensured in the RAM 4. Theplatform 5 b is for providing an operation environment common to theapplication programs even when pieces of hardware serving as basesdiffer from one another, and is constructed with an interface programfor linking the application program and hardware etc. as well as anoperating system (OS) for the application program, which is aconceptually well known part and details of its explanation will beomitted.

Each application program realizes a body system function that is afunction concerned with an operation of several parts of a vehicle by avehicle user. The body system functions include, specifically, a controlassociated with door open and close, a control associated with windowopen and close, a control associated with turning on/off of lightswitches, a control of a wireless door locking adopted for a keylessentry system etc. Specifically, the following can be exemplified:

Locking/unlocking and a power window operation of a driver side door, apassenger side door, a rear right-hand side door, a rear left-hand sidedoor, a roof, etc., and the like

Operations of power supplies of an air-conditioner, a car audio, a carnavigation system, etc.

Controls of turning-on of switches of a room lamp, a cockpit lamp,headlights, small lamps, hazard lamps, tail lamps, etc.

The ECU 1 handles controlling operations of various control targetapparatuses of the body system (devices to be controlled) throughexecution of the application programs while referring to input signalsof switches and sensors from the outside as needed. Moreover, the ECU 1proceeds to a sleep mode under some conditions, such as when the vehicleis in a parking state, or when there is no operation of the switches.Specifically, this transition to the sleep mode is done by making thewhole ECU 1 proceed to a low power consumption mode. In the embodiment,a stand-by mode where a main clock circuit 8 for operating clock for theCPU 3 is halted, when operations of all the application programs haveterminated and are in waiting modes for starting next operations. Itscontrol is assumed by sleep control software 5 c.

As shown in FIG. 3, the scheduler formed as a part of functions of theplatform (acting as a part of functions of the control-software startcontrol) starts and controls a plurality of application programs (1),(2), . . . , (n) periodically in the predetermined time series order.When the execution task of a certain application program comes and arequest of operation to a corresponding function is inputted from theoutside, that application program will be started. When the request ofoperation is not inputted, the execution task of the application programwill be skipped. Then, when a certain time elapses with no operationrequest for a corresponding function being inputted, each applicationprogram becomes able to proceed to the above sleep state. Here,description of “able to proceed to” is given because it is impossible tomake the whole of the CPU 3 proceed to a sleep mode when there is aninput of an operation request to a function that other applicationprogram bears.

Moreover, although the CPU 3 that has temporarily shifted to the sleepmode will wake-up by receiving an outside start request to any of theapplication programs as an external wake-up signal, there also existstart request signals whose inputs cannot be recognized when the CPU 3is waked up at least temporarily. When it is required to start aspecific application program using such an input as a trigger,processing that a corresponding application program is waked up at aconstant time periodically even in the case of being in a sleep stateand is made to proceed to a sleep state again when there is not theabove received input etc. becomes necessary. That is, what is necessaryis processing whereby the CPU 3 is made to proceed to a sleep mode whenthere is no outside operation request to any of the plurality ofapplication programs and subsequently repeat sleep/wake-up periodsconsisting of a constant sleep period and a constant wake-up period inwhich the CPU 3 is waked up into a normal mode to check the presence ofan outside operation request (internal wake-up processing). Thisfunction is implemented by the sleep control software 5 c and a sleepcontrol circuit 7 configured as hardware independent from the CPU 3.

Regarding the internal wake-up processing, requested wake-up periodsgenerally differ depending on each application program, and timing inwhich an application program shifts to a sleep mode again after beingwaked up by an external wake-up signal also differs. The sleep controlsoftware 5 c has a timer routine, grasps reception timings of outsidestart request signals for the application programs. When inputs of startrequest signals for all the application programs cease, the sleepcontrol software 5 c determines that the control unit has entered acommon operation rest period. Then, the sleep control software 5 c alsograsps wake-up periods requested from the application programscollectively, and finds a shortest wake-up period. When a predeterminedtime elapses after entering the above common operation rest period, thesleep control software 5 c sets up the found wake-up period in the sleeptimer provided in the sleep control circuit 7, halts an operation of amain clock circuit 8, and makes the CPU 3 sleep (FIG. 3).

Since the CPU 3 that is once made to sleep halts operations as anoperation circuit, it cannot conduct the wake-up processing by itself.Then, when the wake-up period being set in the sleep timer has elapsed,the sleep control circuit 7 starts the main clock circuit 8 by sending astart signal (internal wake-up signal) to it to resume the operation ofthe CPU 3. It becomes easy to understand these operations by imaging asituation where one falls in a sleep after setting a wake-up clock(sleep timer) in the sleep control circuit 7 by oneself. When the timecomes, the wake-up clock wakes the operator. Then, an interruption startsignal (internal wake-up signal) is also sent to the CPU 3. Receivingthis, the CPU 3 conducts resource setting processing for wake-up by thepredetermined interruption processing and the like and wakes up.

Next, the ECU 1 is, as shown in FIG. 2, connected with other ECUs 1′,1″, etc. through a serial communication bus 30. As shown in FIG. 1, theserial communication bus 30 is connected with internal buses of the ECUsthrough a serial communication interface 6. The serial communicationenables the ECU 1 to receive, for example, data for determining a resetinstruction or a wake-up factor and data about version-up of theapplication program (control software), i.e., data of an update versionprogram. A receiver buffer 6 b is provided for storing the received datatemporarily.

The ROM 5 in which the application program 18 is stored allows storagecontents to be electrically rewritten, and is made up of a nonvolatilememory, in this embodiment a flash ROM (flash memory), that retains thestorage contents even when receiving an outside reset signal. This ROM 5is hereinafter also referred to as a flash ROM. In the flash ROM 5, adrive voltage at the time of reading and a drive voltage at the time ofwriting and erasing are different; the latter (for example 9V) is sethigher than the former (for example 5V; the reset signal is an edgetrigger signal of the same level). That is, since the signal voltage ofwriting/erasing is controlled with a voltage higher than the resetsignal, even when receiving the reset signal, the storage contents ofthe flash ROM 5 are retained. A storage area of the flash ROM 5 isdivided into a plurality of rewriting unit blocks 15. Erasing, writingand rewriting of the storage contests can be conducted on a basis ofrewriting unit block 15. Although FIG. 1 renders a situation where twoapplication programs are stored in one of the rewriting unit blocks 15,the number of the unit blocks 15 may change depending on the size of anapplication program. In the case of an application program of anespecially large size, the application program may be stored over two ormore rewriting unit blocks. In this embodiment, the flash ROM 5 is madeup of a single memory chip, which is partitioned into a first (primary)memory 5P and a second memory 5S each of which is designed to be a fixedmemory consisting of a group of individual rewriting unit blocks.

Moreover, the flash ROM 5 stores rewriting tool (firmware) 5 a asfirmware for updating application program control software. In the ECU 1that will be a destination of application program updating, the flashROM 5 has a formation of a main storage area 20 for storing the currentversion program that is a currently used version program of theapplication program (control software) and a formation of a sub-storagearea 21 for storing an update version program that includes updatedpoints to be updated from the current version program. The rewritingfirmware 5 a is firmware (reprogram processing) for executing programrewrite processing. This processing includes: program store processingthat stores an update version program acquired from the outside in thesub-storage area 21; and memory changeover processing that, when storingof the update version program has ended successfully in the sub-storagearea 21, changes over the sub-storage area 21 to a new main storage areaas the main storage area 20 instead of a memory area currently beingused and, when the writing in the sub-storage area 21 has failed, doesnot conduct the changeover. When the writing of the update versionprogram in the sub-storage area 21 has been done successfully, therewriting firmware 5 a along with both the platform 5 b and the sleepcontrol software 5 c are stored in a base memory 5B that is differentfrom the first memory 5P and the second memory 5S serving as storagedestinations of a group of application programs. The CPU 3 is programmedto, when acquiring an update version program, perform program rewriteprocessing by the rewriting firmware 5 a independently from executionprocessing of the current version program.

In FIG. 1, reference numerals or symbols tagged with “′,” such asapplication program 1′, application program 2′, . . . , represent updateversion programs, and reference numerals or symbols not tagged with “′”represent the current version program, wherein application programshaving the same reference numerals or symbols are the same applicationprogram, but of different versions. The program processing by therewriting firmware is executed in such a way that each time an updateversion program is newly acquired, the sub-storage area is formed ineither the first memory 5P or the second memory 5S alternately.

The first memory 5P and the second memory 5S store programs of aplurality of application programs each having different function,respectively. The main storage area 20 and the sub-storage area 21 forthe same application program are formed in the first memory 5P for oneof them and in the second memory 5S for the other. Since the two piecesof the memory are different, it is evident that the main storage area 20and the sub-storage area 21 for the same application program are formedin mutually different rewriting unit blocks. Specifically, each timeprogram updating occurs in an individual application program, therewriting firmware 5 a determines independently in which of the memories5P and 5S the main storage area 20 and the sub-storage area 21 of thatapplication program are formed. Consequently, the main storage areas 20and the sub-storage areas 21 for different application programs areformed mixedly in the first memory 5P and in the second memory 5S,depending on the number of updating of each application program. Thatis, when the sub-storage areas for two application programs, applicationprogram 1 and application program 2, are formed in different memories,it is because that the number of version-up (updating) is differentbetween the two application programs.

Moreover, the firmware 5 a writes the update version program in thesub-storage area 21 along with version information specifying theversion (Ver.). The firmware 5 a writes a normal termination ID (term.ID) in response to the normal termination of the update version programalong with version information. Regarding the application program 1, theversion information and the normal termination ID are written for thecurrent version program in the main storage area 20. This is because themain storage area 20 was used as the sub-storage area at the time of thelast updating, and the version information and the normal termination IDwere written in that time. On the other hand, regarding the applicationprogram 2, the normal termination ID is not given to the update versionprogram in the sub-storage area 21. This implies that writing of theupdate version program has failed according to a factor, such ascommunication failure.

Hereafter, the electronic control system of an automobile will bedescribed in detail taking as an example a case where the control targetapparatus in FIG. 1 is a car navigation system and a function controlapplication program of the car navigation is updated for version-up. Itis not however intended to limit the present invention to this example.In FIG. 2, it is assumed that an update version program of anapplication program used by the ECU 1 is received by a wireless or radiocommunication unit 31 connected to the ECU 1′. Reception of this updateversion program can be conducted in various forms. For example, in thecase where a delivery time of the update version program from the serveris fixed as a regular version-up and the ECU sends an update versionprogram unilaterally just at that time, it is just necessary for theradio communication unit 31 to autonomously receive the update versionprogram.

Moreover, in the case where an update version program is downloaded andacquired by the user's request, it is also possible to adopt a method inwhich the radio communication unit 31 sends by radio a delivery requestof the update version program to the server, and the radio communicationunit 31 receives an update version program sent by the server inresponse to this. Alternatively, a system where the user sends by radioa distribution request from a portable phone terminal, an update versionprogram is received with the portable phone terminal, and subsequentlyit is transferred to the radio communication unit 31 by a near fieldradio communication technology, such as Blue Tooth, may be adopted. Inany case, the received update version program is downloaded in a fixedstorage unit (for example, flash ROM) in the ECU 1′. In FIG. 2, the ECU1′ informs the ECU 1 of reception of an update version program throughthe serial communication bus 30.

As shown in FIG. 4, when performing the above reprogram processing, atask of the above reprogram processing is incorporated in an executionarray of a plurality of application programs in the scheduler. FIG. 5shows a flowchart concerned with control processing of the scheduler.When a notice of an update version program is received at step S101, theprocessing proceeds to step S102, where a task of reprogram processingby the rewriting firmware is incorporated in the scheduler. By this, thereprogram processing will be performed in parallel in the background ofeach application program.

FIG. 6 shows a flow of sub-storage area determination processing. First,at step S51, a name of an application program to be updated is acquired.At step S52, a storage area of the application program is searched inthe first memory 5P. When there is the corresponding storage area of theapplication program at step S53, the processing proceeds to step S54,where version information written in the storage area is read. Next, atstep S55, a storage area of the application program is searched in thesecond memory 5S. When there is the corresponding storage area of theapplication program at step S56, the processing proceeds to step S57,where version information written in the storage area is read.

Then at step S58, two pieces of version information read from bothmemories are compared, and it is determined which is the older versionat step S59. When the first memory 5P is older, the storage area on thefirst memory 5P is designated as the sub-storage area (step S61); whenthe second memory 5S side is older, the storage area on the secondmemory 5S is designated as the sub-storage area (step S62). That is,designating a storage area where the older version program earlier thanthe current version program is stored as the sub-storage area where thelatest update version program will be stored, processing of overwritingthe update version program there is conducted.

It is noted that when application programs are not stored in the firstmemory 5P and in the second memory 5S correspondingly at steps S53 andS54, it implies that the application program has been installed for oneversion at the highest, and accordingly the sub-storage area that willserve as a storage destination of the update version program will benewly created in the memory where the application program is not stored(steps S62 and S63).

Next, FIG. 7A is a flowchart showing the processing of reprogramprocessing. At step S1, a request to send of program data is sent to theECU 1′ that is specified as a receiver of an update version program.Receiving this, the ECU 1′ creates data frames by dividing the updateversion program into fixed blocks and sends out these frames in theserial communication bus 30. The ECU 1 receives the data block at stepS2. When transmission of the whole of one program has ended, the ECU 1′sends a notice of program transmission completion, the ECU 1 checks thisat step S3.

When there is no notice of the program transmission completion, theprocessing proceeds to step S4, where the ECU 1 stores the received datablocks temporarily in a work area 4 a for program rewriting formed inthe RAM 4 of FIG. 1. Then, the data blocks that were buffered arewritten or copied in the sub-storage area 21 of the flash ROM. At stepS6, when an allocation time for one period of the reprogram processingby the scheduler has not elapsed, the processing returns to step S1 toreceive and write the next data block and repeats the subsequent stepsof the processing. On the other hand, when it is expected that theallocation time times over in the next period, the processing proceedsto step S7, where in order to terminate writing processing of the updateversion program halfway, a file that is being written in the sub-storagearea 21 of the flash ROM is closed temporarily.

Then, as shown in a lower part in FIG. 4, when the task of reprogramprocessing comes again in the next period of the application programstart cycle by the scheduler, reception and writing processing ofsucceeding data block will be resumed. The scheduler always graspswhether the task of the reprogram processing comes by timer measurement.At the time of coming of the task, all the other application programs(control software) has halted to operate (in a start stand-by state). Itis clear that the reprogram processing (program rewrite processing) isperformed in the common operation rest period and that the scheduler hasboth a function of control software start controlling means and afunction of common operation rest period specifying means for specifyinga common operation rest period. Furthermore, when the reception andwriting of the whole update version program has not ended in a singletask of reprogram processing, the reprogram processing of FIG. 7 isrepeated each time the execution period by the scheduler comes.Therefore, it is clear that the program processing is performed by timedivision processing that extends over two or more common operation restperiods coming successively in a sequential manner.

When receiving and writing a first data block, the version informationof the target update version program is written in the sub-storage area,and at the same time normal termination ID has been reset (erased). Whenthe reception and writing of all the data blocks have ended and thenotice of program transmission completion is received at step S3, theprocessing proceeds to step S8, where the normal termination ID iswritten to terminate the reprogram processing. In response to this, thescheduler conducts processing of deleting a task of reprogram processingfrom an execution period. On the other hand, when the reception andwriting of the update version program have failed halfway, the normaltermination ID remains not being written. In FIG. 1, although the updateversion program is written in the sub-storage area 21 in the firstmemory 5P, the normal termination ID is missing because the receptionand writing have failed.

FIG. 8 shows a flow of start processing of an application program afterreprogram processing. At step S151, the name of an application programto be started is acquired. At step S152, a storage area of theapplication program is searched in the first memory 5P. At step S153,when there is a storage area corresponding to the application program,the processing proceeds to step S154, where version information writtenin the storage area is read. Next, at step S155, a storage area of theapplication program is searched in the second memory 5S. When there is astorage area corresponding to the application program, the processingproceeds to step S157, where version information written in the storagearea is read.

Then, at step S158, two pieces of version information read from bothmemories are compared and it is determined which is the older version atstep S159. When the first memory 5P is new, the processing proceeds tostep S160, where it is determined whether there is a normal terminationID in the storage area of the first memory 5P. On the other hand, whenthe second memory 5S is new, the processing proceeds to step S162, whereit is determined whether there is the normal termination ID in thestorage area of the second memory 5S. In both cases, when there is thenormal termination ID, the application program is started from thememory where the new version is stored (from step S160 to step S161 orfrom step S162 to step S163).

When there is not the normal termination ID, the application program isstarted from the memory where the previous version is stored (from stepS160 to step S163 or from step S162 to step S161). It is clear that whatis specified as a start destination of the application program is theabove sub-storage area. At the moment when it is specified as a startdestination and thereafter, the update version program is recognized asa current version program. Accordingly, while what was the sub-storagearea until that moment is raised to be the main storage area, what wasthe main storage is demoted to the sub-storage area. In the next programupdate processing, this relation will be reversed again.

On the other hand, when at steps S153 and S156, either the first memory5P or the second memory 5S does not store a corresponding version of theapplication program, it implies that only one version of the applicationprogram is stored in either memory, and accordingly the applicationprogram shall be started from that memory (step S16 step 7 S170). In anycase, after checking whether the normal termination ID exists for theapplication program version installed solely (step S166, step S169), theprocessing is allowed to shift to start processing of the applicationprogram.

Although the above reprogram processing is performed by incorporating atask in an execution period of a plurality of application programs, thesystem is likely to suppress an operation of the application programbecause the schedule do time-sharing on the reprogram processingforcefully even when the application program is in operation. In view ofthis possibility, when the reprogram processing is tried to be executedso as to fall in a period when all the plurality of application programsdo not have external operation requests, that is, when the CPU isallowed to shift to a sleep state normally, these anxieties can beeliminated. In this case, the common operation rest period shall bespecified as the period when there are no external operation requestsfor all the application programs.

This embodiment takes as an example the case where the sleep modeconsists of the first level sleep mode to which the normal mode canshift directly in a sequential manner and the second level sleep modethat is a sleep mode to which the first level sleep mode can shift aftera predetermined time has elapsed and its power consumption is evensmaller than that of the first level sleep mode. In this case, the sleepcontrol software 5 c of FIG. 1 is configured to make sleep setting bythe first level sleep mode in the common operation rest periodregardless of the acquisition of the update version program. When theupdate version program has been acquired, start the program rewriteprocessing instead of making the mode proceed to the second level sleepmode. In periods when the start request of each application programreduces in number extremely, for example, parking for a long time, it isoften the case where the second level sleep mode is set up as describedabove. Entering the second level sleep mode may be referred to asentering deep sleep, etc. When the program rewrite processing isperformed so as to fall in this period, butting against actualprocessing of the application program occurs hardly, and it becomespossible to rewrite a program of a large size at a time.

For example, in FIG. 1 the sleep control software 5 c and the sleepcontrol circuit 7 can be configured to have the following function(wake-up control). When there is no outside operation request to all ofthe plurality of application programs, the CPU 3 is made to proceed tothe sleep mode, and subsequently repeats sleep/wake-up periodsconsisting of a fixed sleep period and a wake-up period in which the CPUis waked up to the normal mode for a fixed period in order that the CPUchecks whether there is an outside operation request. In this case, asshown in FIG. 9A, the second level sleep mode is set in such a way thatthe length of its sleep period in the sleep/wake-up period is longerthan that of the first level sleep mode.

FIG. 9B shows a detailed example of the sleep control processing in thiscase. This processing is executable even in the sleep period by usingthe internal wake-up period that comes periodically. First, anunillustrated sleep flag is formed in the RAM 4 of FIG. 4. With a setupstate of the sleep flag it can be identified whether the currently setupmode is the first level sleep mode or the second level sleep mode. Atstep S201 in FIG. 9B, this sleep flag is read to determine which levelsleep mode is set up at step S202 and step S203. First, in a timingimmediately after the wake-up by the outside start instruction, thesleep setting itself is not made, and then the processing proceeds tostep S208 from step S203, where it is checked whether there are sleeprequests from any of all the application programs. When there are sleeprequests, the setting of the first level sleep mode (a sleep timecorresponding to the first level sleep mode is set up in the sleep timerin the sleep control circuit 7) is made at step S209, and the sleep flagis changed to a corresponding state at step S210, and the sleep timer isstarted at step S211.

On the other hand, when the sleep flag indicates the first level sleepsetting at step S202, the processing proceeds to step S204, where thesleep timer is read. When the read time exceeds or times up a specifiedtime to proceed to the second level sleep mode at step S205, theprocessing proceeds to step S206, where the second level sleep settingis made. Then at step S207, the sleep flag is rewritten to thecorresponding contents. Moreover, when at step S202 the sleep flag doesnot have the first level sleep setting, the processing proceeds to stepS203. When the sleep flag has the second level sleep setting, theprocessing cycle is terminated.

FIG. 7B shows reprogram processing in this case. At step S0, the sleepflag is read, when it has the second level sleep setting, reprogramprocessing at step S7 and the subsequent steps as with FIG. 7A isexecuted. In this case, the processing will be executed at the time ofwake-up in the second level sleep setting. At step S6′, the processingchecks whether there is an outside wake-up instruction. When there is nowake-up instruction, the processing returns to step S1, where thereprogram processing is continued. On the other hand, when the wake-upinstruction is received, the processing proceeds to step S7 in order togive precedence to this processing and do close processing temporarily.It is when the second sleep level is set up again next that thereprogram processing is resumed.

Second Embodiment

As a second embodiment, the same address space in the nonvolatile memorymay be used by the first memory 5P and the second memory 5S in such away that the memory space is shared by switching over their connectionto the bus. In this case, the memory on the sub-storage area side isconnected to the bus, and rewrite processing of the update versionprogram is performed. In this case, as shown in FIG. 10A, two flashROM's (nonvolatile memories) each of which is designed as an independentmemory chip are provided and made to function individually as the firstmemory 5P or the second memory 5S, respectively, either of which isselectively connected to the bus by the switch 9.

When the rewrite processing has normally ended, what is necessary isjust to use the update version program in the memory connected to thebus for execution as the current version program (as a result, thesub-storage area has been changed over to the main storage area). Atthis time, since the memory having been functioning as the main storagearea at that time is kept disconnected, the CPU 3 cannot see the memory;therefore, it will never occur in terms of hardware that the old versionprogram in the memory would be executed despite the success of theupdate processing.

On the contrary, when the writing procession has not normally ended (orit was stopped halfway because of time division processing or the like),what is necessary is just to switch over the memory connected to the busto the main storage area side memory, and put the current versionprogram before updating into practical use (that is, the previous mainstorage area is used as it is and the changeover is not conducted). Atthis time, the memory having been functioning as the sub-storage areaside is disconnected from the bus, and accordingly it will never occurthat an incomplete update version program whose writing failed isexecuted. According to this system, it is not necessarily essential towrite the version information and normal termination informationdescribed above.

However, in the above system, concerning the memory connected with thebus among the first memory 5P and the second memory 5S, all the programsstored therein need to be current version programs (that is, formedstorage areas all become the main storage areas). In this case, when anupdate version program of a certain program is written in either thefirst memory 5P or the second memory 5S, processing in which the storagecontents of the memory along with remaining application programs arecopied to the other memory as a whole becomes necessary. By thisprocedure, it is possible to save the newest versions of non-updatedapplication programs in the memory that becomes the main storage area bymemory changeover at the time of that memory changeover accompanied withthe next updating.

In FIG. 10A, application programs are stored in the ROM 5B that isdifferent from ROM for the platform 5 b, the rewriting firmware 5 a, andthe sleep control software 5 c. This ROM 5B either may be made up ofmask ROM or be made up of flash ROM.

FIG. 10B shows one example of reprogram processing in this case. Sinceit will take some time to conduct memory copy processing after memorychangeover, reprogram processing that uses a time of sleep as with FIG.7B is adopted. At step S500 that is the top of processing, the contentsof setting of the sleep flag are read and checked as to whether thesecond level sleep setting is made. At step S505, it is checked whetherthe reception of an update version program has ended. When the receptionhas not ended, processing at step S1 to step S7 as with FIG. 7 isperformed. Here, when at step S5, a notice of program transmissioncompletion is received, the processing proceeds to step S501, where thecontents of the memory having been used as the sub-storage area arecopied in the memory having been used as the main storage area (memorycopy processing). This copy processing is executable by repeating thefollowing procedure: the sub-storage area side memory is connected tothe bus; the contents are copied in the RAM 4; the main storage areaside memory is connected to the bus; and the contents of the RAM 4 arewritten in the main storage area side memory.

When the wake-up signal interrupts halfway from the outside, theprocessing proceeds to step S7, where close processing is conducedtemporarily. Then when the second level sleep setting is able to bechecked (step S500), it now means “reception completion” and theprocessing proceeds to step S506 from step S505. When the memorychangeover has not been done, the processing proceeds to step S501,where the memory copy processing will be continued. When the copycompletion is checked at step S503, the processing proceeds to stepS504, where a changeover signal is sent to the switch 9 (FIG. 10A) andthe memory having been used as the sub-storage area is connected to thebus. At the same time, the memory changeover processing to disconnectthe memory having been used as the main storage area from the bus isconducted. It is noted that when the reprogram processing has ended anda next update version program is not received, the processing proceedsas step S505, step S506 and then end, and processing concerned with thereprogram will not be performed at all.

Third Embodiment

Referring to FIG. 11 showing a third embodiment, an ECU 301 has a maincontrol unit made up of a CPU 303 and performs control processing ofelectronic apparatuses (control target apparatuses; devices to becontrolled) mounted on an automobile based on execution of thepredetermined application program (function controlling software) by themain control unit. Specifically the ECU 301 further has a ROM 305, a RAM304, and a microprocessor to which I/O units (I/O ports) 302 arebus-connected. In this embodiment, the ECU 301 is constructed as a bodysystem ECU that handles a control of a body (chassis) system of anautomobile. Each application program 318 is stored in the ROM 305 andoperates on a platform 305 c stored similarly on the ROM 305, and anindividual work area 304 d is secured in the RAM 304. The platform 305 cprovides an operation environment common to each application programeven when hardware serving as a base is different, and consists of aninterface program that allows coordination between the applicationprogram and the hardware and the like as well as an operation system(OS) for the application program. In addition, a start controlling meansis also incorporated in this platform 305 c and run by the CPU 303 usingthe work area 304 c in the RAM 304.

The application program realizes the body system functions that arefunctions concerned with operations on various parts of a vehicleconducted by the vehicle user. Specifically, the body system functionsinclude a control associated with door opening/closing, a controlassociated with window opening/closing, a control associated withturning on/off light switches, a control of a wireless door lockmechanism adopted for a keyless entry system, etc. Specifically, thefollowing can be exemplified:

Locking/unlocking of a driver side door, a passenger side door, rearright-hand door, a rear left-hand door, a roof, etc. and a power windowoperation thereof

Power-source operation of an air-conditioner, a car audio, acar-navigation system, etc.

Controls of turning on a room lamp, a cockpit lamp, a headlight, a smalllamp, and a hazard lamp, a tail lamp, etc.

The ECU 301 is connected with other ECUs through a serial communicationbus 330, and the serial communication bus 330 is connected with aninternal bus of each ECU through a serial communication interface 306.The communication firmware 305 b handling processing of datatransmission and reception through the serial communication bus is alsostored in the ROM 305, and is put into execution by the CPU 303 usingthe work area 304 b in the RAM 304.

The memory content of the ROM 305 in which the software is stored can beelectrically rewritten, and the ROM 305 is constructed as a nonvolatilememory capable of maintaining the memory content even when receiving areset signal from the outside. In this embodiment the ROM 305 is made upof a flash memory (flash ROM 305). In the flash ROM 305, the drivevoltage in reading and the drive voltage in writing/erasing aredifferent; the latter (for example, 9 V) is set higher than the former(for example, 5 V; the reset signal is an edge trigger signal of thesame level). That is, since the control is done with the signal voltageof writing/erasing being higher than the voltage of the reset signal,the memory content of the flash ROM 305 is maintained even whenreceiving the reset signal. The memory area of the flash ROM 305 ispartitioned into a plurality of rewriting unit blocks, which allows thememory content to be erased, written, and rewritten on a rewriting unitblock basis.

Moreover, the flash ROM 305 stores rewriting firmware 305 a forrewriting the contents of the application program stored in the flashROM 305 (this storage area is a rewriting firmware storage part). Therewriting firmware 305 a performs rewrite processing by acquiring dataof the update version program of the application program that is atarget of rewriting (version-up) and writing it in the flash ROM 305 bythe above unit block using a rewriting work area of the RAM 304 as abuffer area. The data sender apparatus is, for example, a programrewriting tool 310 connected to the serial communication bus 330 througha connector 309. This program rewriting tool 310 is configured as acomputer terminal having the fixed storage for storing data of an updateversion program of the application program. The data sender apparatusmay be another ECU that receives the update version program data from anexternal radio communication network with a radio communication unit331.

As shown in FIG. 12 showing the storage area of the application program318 in the flash ROM 305, this area has a formation of a rewriting-stateidentifying ID storage part (rewriting-state identifying informationstorage part: hereinafter also referred to simply as “identifying IDstorage part”) 401 a. This part 401 a stores the under-rewriting stateidentifying ID (rewriting-state identifying information; hereinafteralso referred to simply as “identifying ID”) for identifying whether therewrite processing of the application program 318 by the rewritingfirmware 305 a has normally completed. In this embodiment, a header 401made up of a fixed address area is formed at the top of the storagearea, and the program body storage part 402 is formed in the form thatfollows the header 401. The header 401 has a formation of storage partsfor an application program name, a top address of the program main body,and a tail address thereof, and a formation of the identifying IDstorage part 401 a described above. The addresses of the identifying IDstorage part 401 a are also fixed.

Moreover, the ECU 301 is equipped with functions of the identifyinginformation rewriting means that controls a progress state of therewrite processing by the rewriting firmware 305 a and rewrites thememory content of the identifying ID in the identifying ID storage part401 a according to the progress state in such a way that makes itpossible to grasp whether the rewrite processing has normally completed.In this embodiment, the rewriting firmware 305 a also has the functionsof the identifying information rewriting means. However, this firmwaremay be a separate firmware different from the rewriting firmware 305 a.Moreover, the ECU 301 has a function of the start controlling means of:when starting the application program 318, referring to the memorycontent of the identifying ID storage part 401 a; when the memorycontent indicates normal completion of the rewrite processing, startingthe application program; and when the memory content indicates faultycompletion of the rewrite processing, restarting the rewriting firmware305 a instead of the application program 318, which is doneindependently from the application program 318. This function isincorporated in the platform 305 c in this embodiment.

FIG. 14 shows schematically one example of the simplest case of therewrite processing by the rewriting firmware 305 a. As shown in FIG. 12,here, the identifying ID shall be composed of a 1-bit data, wherein “0”is assigned to under-rewriting and “1” is assigned to rewritingcompletion (naturally, the correspondence may be done conversely) andother states shall not be identified. By receiving a notice of rewritingstart, as shown in FIG. 12, from the rewriting tool 310 (data senderapparatus) connected to the connector 309, the rewriting firmware 305 ais started. The rewriting firmware 305 a, in its start, invalidates thestorage state of the identifying ID storage part 401 a in FIG. 11 as ofbefore start of the firmware. It is considered that there are variousways to implement this invalidation method. In this embodiment, theidentifying ID is reset to “0” indicating under-rewriting. As a result,in the identifying ID storage part 401 a, its invalidated state becomessubstantially equivalent to a content indicating under-rewriting. Inother words, it can be said that processing of invalidating a storagestate before the start of the firmware is also used for processing ofsetting the storage state to “0” indicating under-rewriting. It is alsopossible to invalidate the identifying ID storage part 401 a regardlessof the memory content thereof by providing an identifying ID storagepart invalid flag separately and establishing a flag value indicatingthe invalidation. In this case, resetting this identifying ID storageinvalid flag makes the identifying ID storage part 401 a valid, showingthe under-rewriting state that reflects the memory content.

On the other hand, when the rewriting firmware 305 a received a noticeof rewriting completion from the rewriting tool 310 and has normallycompleted the rewrite processing of the application program 318 in theflash memory ROM 305, the rewriting firmware 305 a sets a storage stateof the identifying ID storage part 401 a to a predeterminedrewriting-normally-completed state “1” indicating that the rewriting hasnormally completed. Subsequently, when the application program 318 isintended to be started again by resetting the ECU 301, the platform 305c permits the start of the application program 318 only when the memorycontent of the identifying ID storage part 401 a is therewriting-normally-completed state “1.”

Meanwhile, the rewriting firmware 305 a maintains the under-rewritingstate “0” being set in the identifying ID storage part 401 a until therewrite processing of the application program 318 is normally completed.When the rewrite processing has been interrupted halfway, the memorycontent of the identifying ID storage part 401 a is still in therewriting state “0.” When the ECU 301 is reset after that, the platform305 c checks that the memory content is the under-rewriting state “0,”starts the rewriting firmware 305 a without starting the applicationprogram 318 currently being in an incomplete under-rewriting state,acquires the data of the update version program from the rewriting tool310 once more, and performs the rewrite processing using it.

As described above, the rewriting firmware 305 a acquires the updateversion program of the application program 318 to be used for rewritingfrom the program rewriting tool (data sender apparatus) 310 connected tothe ECU 301 through a network by communication and performs rewritingwith it. The program rewriting tool 310 outputs continuously aninstruction of maintaining a state of rewriting (namely, an instructionthat instructs to maintain a value of the identifying ID at “0”) to therewriting firmware 305 a during the above rewrite processing. Therewriting firmware 305 a receives the above instruction of maintaining astate of rewriting and maintains the memory content of the identifyingID storage part 401 a at the under-rewriting state (“0”).

Specifically, the rewriting tool 310 sends sequentially the updateversion program as divided into blocks 402 b to the rewriting firmware305 a of the ECU 301. Each time sending one block, the tool 310continuously issues and sends a corresponding instruction of maintaininga state of rewriting. The rewriting firmware 305 a writes a receivedblock in the flash ROM 305, and at the same time continues to maintainthe identifying ID value at “0” receiving the instruction of maintaininga state of rewriting sent thereto as occasion arises. It is noted that,although the rewriting firmware 305 a has received the data block, when,due to some cause, the instruction of maintaining a state of rewritinghas been ceased, the rewriting firmware creates an error log and endsthe processing.

Moreover, when the rewriting firmware 305 a has written the whole updateversion program in the flash ROM 305 received by the rewriting firmware305 a, the program rewriting tool 310 starts the transmission ofverifying data for verifying the sent update version program data. Theverifying data may be either one that is the same as the update versionprogram data or data for error check made by processing the updateversion program, such as a checksum code. Also regarding this verifyingdata, the program rewriting tool 310 continues to issue and send aninstruction of maintaining a state of rewriting for each block. Therewriting firmware 305 a, in response to the above verifying data,verifies the update version program data already written in the flashROM 305. In response to an instruction of maintaining a state ofrewriting, the firmware 305 a maintains the identifying ID at theunder-rewriting state “0.” Then, when verification of the whole updateversion program is completed, the rewriting firmware 305 a will rewritethe identifying ID as rewriting-normally-completed state, i.e., “1.”

In FIG. 15, the processing of the rewriting tool 310 is shown in theleft hand, and the processing of the rewriting firmware 305 a in theright hand, with time series of the execution step being almostcoincided, and communication flows of information between the rewritingtool 310 and the ECU 301 are shown by broken lines. The step numbers areshown by “S##” on the rewriting tool 310 side and by “T##” on therewriting firmware 305 a side. In order to make it easy to grasp whichflow is currently explained, the explanation of the rewriting tool andthe explanation of the firmware will be given in separate paragraphs,respectively. Moreover, a transmission destination when “transmission”is referred to in the rewriting tool side always indicates the firmware305 a; a transmission destination when “transmission” is referred to inthe firmware side always indicates the rewriting tool 310.

(Rewriting tool) A notice of rewriting start is sent at step S301.

(Firmware) The notice of rewriting start is received at step T301, theinvalidation described above is conducted by setting the identifying IDto “0” (“0” also used for setting of writing). The acknowledge signalACK is returned at step T303.

(Rewriting tool) At step S302, it is checked whether the acknowledgesignal ACK is received. A data block to be transmitted is sent at stepS303 and an instruction of maintaining a state of rewriting formaintaining the identifying ID at “0” is sent.

(Firmware) At step T304, the data block is received. The data is writtenin the flash ROM 305 and the identifying ID is maintained at “0” at stepT305. The acknowledge signal ACK is returned at step T306.

(Rewriting tool) At step S304, the acknowledge signal ACK is received.It is checked whether there is the next data block at step S305. Whenthe result is YES, processing of steps S303 and S304 is repeated.Otherwise, when there is no next data block at step S305, the processingproceeds to step S306, where a notice of verification start is sent.

(Firmware) When the next data block is received at step T307, processingof step S T304-T306 is repeated. Otherwise, when there is no next blockat step T307, the processing proceeds to step T308, where the notice ofverification start is received, and the acknowledge signal ACK isreturned at step T309.

(Rewriting tool) The acknowledge signal ACK is received at step S307,verifying data to be transmitted (data corresponding to the already sentdata will be sent sequentially) is sent at step S308, and theinstruction of maintaining a state of rewriting for maintaining theidentifying ID at “0” is sent. The verification data corresponding tothe already sent data blocks will be sent sequentially in the next andsubsequent step S.

(Firmware) At step T310, the verifying data is received. It is comparedwith corresponding data block written in the flash ROM 305 at step T311,and the result is sent at step T312 (this transmission also serves asacknowledge to the verifying data reception).

(Rewriting tool) At step S309, receiving the above comparison result, itis checked whether the result shows agreement (same verifying data).When the result is agreement, it is checked whether there is nextverifying data at step S310. When the result is YES, the processing atsteps S308 and S309 is repeated. Otherwise, when there is no nextverifying data at step S310, the processing proceeds to step S311, wherea notice of rewriting completion is sent. On the other hand, when theresult shows disagreement at step S309, the processing proceeds to stepS313, where an error log is created and the processing is ended.

(Firmware) When the data block agrees with the verifying data at stepT313, the processing proceeds to step T314, where the identifying ID ismaintained at “0.” When there is the next verifying data at step T315,processing of step T310 to T314 is repeated. Otherwise, when the resultshows disagreement at step T313, the processing proceeds to step T319,where an error log is created and the processing is ended. On the otherhand, when there is no next verifying data at step T315, the processingproceeds to step T316, where a notice of rewriting completion isreceived. Then the identifying ID is set to “1” at step T317, and anacknowledge signal ACK is returned at step T318. In addition, also whennecessary data is not normally received from the rewriting tool at stepsT304 and T310, the processing proceeds to step T319 after apredetermined number of retrials, where an error log is created and therewriting is ended.

(Rewriting tool) When an acknowledge signal ACK is received at stepS312, the processing is ended. In addition, when there is no acknowledgesignal ACK at steps S302, S304, S307 and S312, the processing proceedsto step T313 after a predetermined number of retrials, where an errorlog is created and the processing is ended.

When the rewrite processing by the update version program has completedin the above way, start processing after the reset on and after the nexttime will be as shown in FIG. 16 by the start controlling programroutine run by the platform 305 c. First, the name of the applicationprogram to be started is specified at step T351. At the time of aninitial trial of rewriting by the rewriting tool 310, the content of therewriting ID should be “1” indicating normal completion, and therefore alogic of shifting to the rewrite processing is not true fromdetermination of the content of the rewriting ID. Accordingly, first, itis checked whether there is an interrupt request to start the rewritingfirmware from the rewriting tool 310 (data sender apparatus) at stepT352. When there is no interrupt request, the processing proceeds tostep T353, where the identifying ID corresponding to the applicationprogram is read in the flash ROM 305. When the identifying ID is “1”(normal completion), the processing proceeds to T357, where theapplication program is started. On the other hand, when the identifyingID is “0” (under-rewriting), it indicates that the last rewriteprocessing has not normally completed, and consequently, the processingproceeds to step T355, where the rewriting firmware 305 a is started torequest the rewriting tool to start the rewrite processing program atstep T356 (indicated by the left-hand flow in FIG. 15). On the otherhand, when there is the interrupt request at step T352, the processingskips steps T353-T355 and proceeds to step T356, where start of therewrite processing program is requested to the rewriting tool.

Various modification embodiments are possible, as described below, usingthe above processing example as a base. First, the rewriting firmware305 a can be configured to, when the rewrite processing is interruptedduring the verification, set the memory content of the identifying IDstorage part 401 a to the under-rewriting state in such a way that theinterruption can be specified as interruption during verification.Corresponding to this, the platform 305 c can be configured to restartthe rewriting firmware 305 a so that the rewrite processing is resumedfrom the verification processing. FIG. 13 shows a setting example of theidentifying ID of this case. In order to identify three or moreunder-rewriting states, the identifying ID shall be two or more bits, inthis case 2 bits, wherein “00” is assigned to represent an unrewrittenor still-rewriting state (also used to represent the invalidation), “01”to represent a rewritten-unverified (still verifying) state, “00” torepresent a rewriting-normally-completed state (both rewriting andverification completed).

FIG. 17 shows a flow of the rewrite processing of this modification.Since there are many steps common to those in FIG. 15, steps whoseprocessing contents are the same of those of FIG. 15 are designated withthe same step numbers and detailed explanations thereof will be omitted.Moreover, steps whose processing contents are different from those ofthe steps of FIG. 15 are additionally given “a” for the step numbers inorder to make clear a corresponding relation to FIG. 15.

Steps S303 a, T302 a, T305 a and T317 a are not different tocorresponding steps in FIG. 15 in essential processing, except that theidentifying ID “0” that indicated in rewriting now changed to theunrewritten “00” and the identifying ID indicating rewriting completionchanges to “10” from “1.” On the other hand, at steps S308 a and T314 aconcerned with the verification, the processing of FIG. 15 only conductsthe processing of maintaining “0” indicating under-rewriting; thisprocessing here newly sets “01” indicating rewritten-unverified. As aresult, when the processing has been interrupted during the writing ofthe update version program, the identifying ID is set to “00.” When ithas been interrupted during the verification, the identifying ID is setto “01.” These two cases can be differentiated.

FIG. 18 shows an after-reset start processing of this case. When thereis no interrupt request for the starting of rewriting firmware from therewriting tool 310 (data sender apparatus) at step T352, the identifyingID is read at step T353. When the content is “00,” programs of both therewriting tool and the rewriting firmware are started from tops, thatis, locations (A) and (A′) in FIG. 17, the rewrite processing of theupdate version program and subsequent steps are repeated again (stepsT361, T362). On the other hand, when the content of the identifying IDis “01,” the programs of both the rewriting tool and the rewritingfirmware are started from a verification processing step, that is,locations (B) and (B′), and only the verification processing is repeatedin FIG. 17 (steps T363, T364). When the content of the identifying ID is“10,” the application program (update version program) is started. It isnoted that when there is an interrupt request at step T352, theprocessing proceeds to T361.

Next, the rewriting firmware 305 a may be configured to, when therewrite processing of the application program into the flash ROM 305 isinterrupted halfway, set the memory content of the identifying IDstorage part 401 a in the under-rewriting state in such a way that aninterruption location of the rewrite processing (including verificationprocessing of written data in addition to write processing into theflash ROM 305) is identifiable. In this case, the platform 305 cidentifies the interruption location for the memory content of theidentifying ID storage part 401 a and restarts the rewriting firmware305 a so that the rewriting is resumed from the interrupted location.Specifically, as shown in FIG. 19, a plurality of identifying ID storageparts 401 a can be provided corresponding to blocks of the updateversion programs 402 b, respectively. The rewriting firmware 305 a canbe configured to set storage states of the plurality of identifying IDstorage parts 401 a to the rewriting-normally-completed statessequentially on a first-completion first-setting basis “10”. Theplatform 305 c shall restart the rewriting firmware 305 a in such a waythat the rewrite processing is resumed from the block 402 b whosestorage state of the identifying ID storage part 401 a is not set to therewriting-normally-completed state “10”.

In FIG. 19, a storage area of the flash ROM 305 for the applicationprogram 318 has a formation of block-based identifying ID storage parts402 a each used to identify a state of each block 402 b at apredetermined address in a storage area of each block 402 b,individually. Moreover, the storage area has a formation of the mainidentifying ID storage part 401 a used for identifying anunder-rewriting state of the whole update version program in addition tothe block-based identifying ID storage parts 402 a. In FIG. 19, thestorage part 401 a is in the header 401. Among these, a main (primary)identifying ID is configured to allow the whole program to be identifiedin either of only two states: under-rewriting “0” (“0” is also used torepresent the invalidation); and rewriting normal completion “1”(therefore, it is 1-bit data). On the other hand, the block-basedidentifying ID is configured to allow each block to be identified in oneof three states of the each block: unrewritten “00” (also used torepresent the invalidation); rewritten-unverified “01”; andrewriting-normally-completed “10” (therefore, it is 2-bit data).

FIG. 20 shows rewrite processing in this case. Steps of FIG. 20different from those of the steps of FIG. 17 are additionally given “b”for the step numbers in order to make clear a corresponding relation toFIG. 17. Hereafter, explanation will be given focusing on steps giventhis “b.”

At step T302 b on the firmware side, when a notice of rewriting start isreceived, the main identifying ID is reset to “0,” all the block-basedidentifying IDs are reset to “00” to invalidate a previous history.Steps S303 b, 5308 b, T305 b, and T314 b are almost the same ascorresponding steps of FIG. 17, respectively, in essential processing.However, the identifying ID shall be set to “00” when the rewritingstate is before rewriting (unrewritten) and set to “01” when therewriting state is the rewritten-unverified in the identifying IDstorage part of a block concerned with current processing, not in asingle identifying ID storage part irrelevant to the block. Each timethe writing/verification of a block makes progress, the setting will beconducted in the identifying ID storage part of a corresponding blocksequentially. When all the blocks have undergone the verification, themain identifying ID will be set to the rewriting-normally-completed “1”at step T317 b.

FIG. 21 shows start processing after the reset of this case; the name ofthe application program is specified at step T401, and the mainidentifying ID is read at step T403 when there is no interrupt requestto start the rewriting firmware from the rewriting tool 310 (data senderapparatus) at step T402. At step T404, when the content of the mainidentifying ID is “1,” the application program (update version program)is started. Thus, by using the main identifying ID separately from theblock-based identifying ID, it can be determined immediately whether therewriting has been normally completed without referring to the contentsof multiple block-based identifying IDs, and the processing can shift tothe start processing of the application program quickly.

On the other hand, when at step T404, the content of the mainidentifying ID is “0,” the processing shifts to analysis processing ofthe identifying ID at step T405 and subsequent steps. Basically, theprocess identifies an interruption location of writing or verification(interruption block) by tracing the blocks in the order of writing (andverification) and finding out at which block the content of theblock-based identifying ID changes. First, the block number “i” isinitialized at step T405, a block-based identifying ID is read at stepT406, and its content is checked at step T407. Considering a logic inwhich writing and verification are sequentially conducted in apredetermined block array, when the content of the block-basedidentifying ID is the rewriting-normally-completed “10” at step T407, atleast verification should have completed in block after that.Accordingly, the block number is incremented at step T408 to return tostep T406 and the processing after that step is repeated. Moreover, whenat step 7409, “i” is “n” (last block), it indicates that all the blockshas normally rewritten, and therefore the processing proceeds to stepT415, where the application program is started. Furthermore, when thecontent of the block-based identifying ID is the unrewritten “00” atstep T407, the firmware and the rewriting tool are started so that therewriting is resumed from that block (steps T418, T419).

When the content of the block-based identifying ID read at step T406 isthe rewritten-unverified “01,” the existence of a block with therewriting-normally-completed “10” has been checked. Therefore, therewriting of further blocks has normally completed, and all blocks aheadof the current block are the rewritten-unverified, provided that theblock is not a top block (at step T411, the determination is YES).Therefore, the processing proceeds to step T412 and step T413, where thefirmware and the rewriting tool are started so that the verification isresumed from that block.

On the other hand, when the block with the rewritten-unverified “01” isa top block at step T411, the processing proceeds to step T414, where itis checked at which block the identifying ID changes to the unrewritten“00” (T415); when all the blocks up to the last block are therewritten-unverified “01,” the firmware and the rewriting tool arestarted so that the verification is resumed from the first block (T416,T417 to T412). On the other hand when it is turned out that theidentifying ID is the unrewritten “00” from a block halfway at stepT415, the processing proceeds to step T418, where the firmware and therewriting tool are started so that the rewriting is resumed from thatblock (at steps T418 and T419).

As a further modification, as shown in FIG. 22, the block-basedidentifying ID storage may be separated from the storage areas of theblocks, and may be formed in the form of another table. In FIG. 22, aset of all the block-based identifying ID storage parts are formed alongwith the main identifying ID in the header 401. Alternatively, withoutproviding the identifying IDs in separated blocks, rewriting-stateidentifying information may be formed by combining informationspecifying a block currently under processing and information of itsprocessing state. In an example of FIG. 23, a block counter N that isincremented each time the processing proceeds to processing of the nextblock and the state ID are combined. The identifying ID indicates thestate of a block indicated by the block counter N, and is configured tobe able to identify three states: the unrewritten state “00” (“00” isalso used to represent the invalidation); the rewritten-unverified state“01”; and the rewriting-normally-completed state “10.”

FIG. 24 shows rewrite processing of this case. The steps in FIG. 24different from the steps in FIG. 20 in processing content areadditionally given “c” to the step numbers in order to make clear acorresponding relation to FIG. 20. Hereafter, explanation will be givenfocusing on steps given this “c.”

At step T302 c on the firmware side, when a notice of rewriting start isreceived, the main identifying ID is set to “0,” the block counter N isset to “1,” and the state ID is set to “00,” respectively, and pastrecords are made invalid. Steps S303 c, S308 c, T305 c and T314 c arealmost the same as the steps corresponding to those in FIG. 20 inessential processing, but a single identifying ID being not related tothe block is used. As the processing shifted to processing of a furtherblock, a state value of a block indicated by the block counter N iswritten in the identifying ID, updating its value. In the processinghere, when writing of a certain block is ended, processing of verifyingthe block shall be conducted. That is, as the processing progresses fromrewriting to verification with the value of the block counter N beingfixed, the value of the identifying ID is rewritten from “01” to “10.”Then, when shifting to processing of the next block at step T320, theblock counter N is incremented and the value of identifying ID isinvalidated again (“00”). Then, when verification of the last block hasended, the processing proceeds to step T317 c, where the mainidentifying ID is set to “1.”

In after-reset start processing of this case, when the main identifyingID is “0” (under-rewriting), it can be immediately grasped by readingthe value of the block counter N and the identifying ID, in which blockand to which state the processing has proceeded. For example, in FIG.23, since N is 54 (by 10 combination) and the state ID is “01,” theseindicate that the processing has been interrupted at the rewriting ofthe 54-th block. Therefore, what is necessary for subsequent processingis just to resume the processing from verification of the 54-th block.

The above embodiments will be modified further in many ways withoutdeparting from the spirit of the invention.

What is claimed is:
 1. An electronic control system for an automobile,comprising: a nonvolatile memory for storing function controllingsoftware for handling control processing of electronic apparatusesmounted on an automobile whose memory content is electrically rewritableand that retains the memory content even when receiving an outside resetsignal, the nonvolatile memory including rewriting firmware storage partthat stores a rewriting firmware for rewriting the content of thefunction controlling software, and the nonvolatile memory furtherincluding rewriting-state identifying information storage part forstoring rewriting-state identifying information with which it isidentified whether rewrite processing of the function controllingsoftware has normally completed in a rewritable manner; a RAM forserving as an execution memory of the function controlling softwarebased on which the control processing of the electronic apparatuses areperformed; identifying information rewriting means that controls aprogress state of the rewrite processing by the rewriting firmware and,depending on the progress state, rewrites a memory content ofrewriting-state identifying information in the rewriting-stateidentifying information storage part to enable to grasp whether therewrite processing has normally completed; and start controlling meansthat refers to the memory content of the rewriting-state identifyinginformation storage part in starting the function controlling softwareand that, when the memory content is a content indicating normalcompletion of the rewrite processing, starts the function controllingsoftware, and, when the memory content indicates incomplete completionof the rewrite processing, executes processing of restarting therewriting firmware instead of the function controlling softwareindependently from the function controlling software; wherein theidentifying information rewriting means sets the memory content of therewriting-state identifying information storage part to a predeterminedunder-rewriting state indicating under-rewriting in response to thestart of the rewrite processing of the function controlling software bythe rewriting firmware, and maintains the under-rewriting state untilthe rewrite processing of the function controlling software is normallycompleted; the rewriting control means starts the rewriting firmwarewhen the memory content of the rewriting-state identifying informationstorage part is under-rewriting state; the rewriting firmware isconfigured to acquire by communication an update version program of thefunction controlling software to be used for the rewriting from a datasender apparatus network-connected to the control system; theidentifying information rewriting means is configured to maintain thememory content of the rewriting-state identifying information storagepart at the under-rewriting state by receiving an instruction ofmaintaining a state of rewriting received from the data senderapparatus; the rewriting firmware receives the update version program asdivided into a plurality of blocks sequentially from the data senderapparatus; the identifying information rewriting means sets the memorycontent of the rewriting-state identifying information storage part tothe under-rewriting state in the form that enables to specify in whichblock the rewriting processing has been interrupted, when the rewritingfirmware interrupts halfway the rewriting processing in the nonvolatilememory by the function controlling software; and the start controllingmeans specifies the block where the processing was interrupted from thememory content of the rewriting-state identifying information storagepart and restarts the rewriting firmware so that the rewritingprocessing is resumed from the block as specified as an interruptedblock.
 2. The control system according to claim 1, wherein: a pluralityof the rewriting-state identifying information storage parts areprovided corresponding to the blocks of the update version program; theidentifying information rewriting means sets a storage state of theplurality of the rewriting-state identifying information storage partsto the rewriting-normally-completed state sequentially on afirst-completion first-setting basis; and the start controlling meansresumes the rewriting firmware in such a way that the rewritingprocessing is resumed from a block whose storage state of therewriting-state identifying information storage part is not set to therewriting-normally-completed state.
 3. The control system according toclaim 1, wherein: the identifying information rewriting means sets eachof the memory contents indicating the normal completion of the rewriteprocessing, the incomplete completion of the rewrite processing and thepredetermined under-rewriting of the rewriting processing as a 2-bitdata.